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Abstract 

A logic for reasoning about timing properties of concurrent programs is presented. The logic 
is based on Hoare-style proof outlines and can handle maximal parallelism as well as certain 
resource-constrained execution environments. The correctness proof for a mutual exclusion 
protocol that uses execution timings in a subtle way illustrates the logic in action. A soundness 
proof using structural operational semantics is outlined in the appendix. 

Key words: concurrent program verification, timing properties, safety properties, real-time 
programming, real-time actions, proof outlines. 


1 Introduction 

A safety property [9] of a program asserts that some proscribed “bad thing” does not occur during 
execution. To prove that a program satisfies a safety property, one typically employs an invariant, a 
characterization of current (and possibly past) program states that is not invalidated by execution. 
If an invariant I holds in the initial state of the program and I Q is valid for some Q , then 
-I Q cannot occur during execution. Thus, to establish that a program satisfies the safety property 
asserting that does not occur, it suffices to find such an invariant /. 

Timing properties are safety properties where the “bad thing” involves the time and program 
state at the instants that various specified control points in a program become active. 1 Timing 
properties can concern externally visible events, like inputs and outputs, as well as events and data 
that are internal to a program, like the value of a variable or the time that a particular command 
starts or finishes. For example, in process control applications, the elapsed time between a stimulus 
and response may have to be bounded. This is a timing property where the “bad thing” is defined 
in terms of the time that elapses after one control point becomes active until some other control 
point does. Timing properties concerning internal events are useful in reasoning about ordinary 

*A preliminary version of this work appeared in Real-time: Theory and Practice , Proceedings of REX workshop, 
June 1991, Springer- Verlag Lecture Notes in Computer Science, volume 600. 

^Supported in part by the Office of Naval Research under contract N00014-91-J-1219, the National Science Foun- 
dation under Grant No. CCR-8701103, DARPA/NSF Grant No. CCR-9014363, and a grant from IBM Endicott 
Programming Laboratory. 

^Supported in part by NSF grant CCR-9003441. 

^Supported in part by Defense Advanced Research Projects Agency (DoD) under NASA Ames grant number NAG 
2-593, and by grants from IBM and Siemens. 

informally, the active control points at any instant are determined by the values of the program counters at that 
instant. See [15] for a more formal definition. 
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concurrent programs that exploit knowledge of command execution times to coordinate processes. 
One such protocol — for mutual exclusion — is given in section 4. 

Because timing properties are safety properties, the invariant-based method outlined above for 
reasoning about safety properties can be used to reason about timing properties. This means that 
a programming logic L to verify (ordinary) safety properties can form the basis for a logic L to 
verify timing properties. It suffices that in L' we are able to: 

(a) specify in I and Q information about the times at which events of interest occur and 

(b) establish that program execution does not invalidate such an I. 

Point (a) means that in defining L ' , the language of L might have to be extended so that it becomes 
more expressive. Point (b) means that the inferencing apparatus of L might have to be refined 
so that / can be proved an invariant for a program whose semantics includes information about 
execution timings. 

A logic for timing properties will, of course, depend on the execution model for programs. Like 
[14], we consider two kinds of actions, ordinary actions, which can take any amount of time to 
execute, and real-time actions, which have constant upper and lower bounds on their execution 
time. Real-time actions allow the modelling of schedulers typically found when multiprogramming 
is employed to implement processes. 

This paper describes extensions to a logic of proof outlines [15] to enable verification of timing 
properties for concurrent programs. The approach taken is the one just outlined: we start with 
a logic for proving ordinary safety properties, augment the language according to (a) and refine 
the inference rules according to (b). The presentation is organized as follows. In Section 2 we 
describe Proof Outline Logic for non-real- time programs. Then, in Section 3, we describe additional 
mechanisms needed to handle real time. In particular, we describe changes that must be made to 
the Rule of Consequence and to the definition of non-interference. In Section 4, we illustrate the 
use of our logic on a mutual exclusion protocol. Section 5 contains discussion of related topics. 

An appendix summarizes a Plotkin-style [13] structural operational semantics and soundness 
proof. The full details of the soundness proof will appear in [2]. Our proof builds a natural model, 
similar to models built by other researchers in the theory of concurrent programming languages[6, 
18, 1, 13]. This method of construction argues for the reasonability of the logic and language as 
well as proving its soundness, in much the same way that, for example, having the integers as a 
model of an arithmetic system, or the Scott models for a A-calculus, give more plausibility than a 
term model does. 

2 Ordinary Proof Outline Logic 

In order to reason about a program, we must be able to characterize sets of program states and 
reason about them. First-order predicate logic is an obvious choice for this task, and we employ 
the usual correspondence between the formulas of the logic and the programming language of 
interest — each variable and expression of the programming language is made a term of the logic 
and each Boolean expression of the programming language is made a predicate of the logic. It will 
be convenient to assume that predicates and terms are always defined, although the value of a term 
may be unspecified in some states. For example, we will assume that the term x/y has a value 
whatever value y has, but that y x {x/y) need not equal when y is 0 because the value of x/y is 
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unspecified in such states.^ 

Predicates and function symbols for the programming language’s data types provide a way to 
express facts about program variables and expressions. Type declarations in the program in uce 
axioms concerning the values that may be assumed by the variables they declare. For simplicity, 

we take these as given. . , , 

The state of a program also includes information that tells what atomic actions migh 

executed next. For representing this control information, we fix some predicate symbols, called 
control predicates , and give axioms to ensure that, as execution proceeds changes m the values of 
the control predicates correspond to changes in program counters. (An alternative represen a ion 
would have been to define a “program counter” variable and a data type for the values it can 

assume.) 


2.1 Control Predicates 

A program is a structured collection of labelled commands, although we omit labels in program 
texts unless they are needed. Each command comprises one or more atomic actions. The defining 
characteristic of an atomic action is that its execution is performed as a single indivisible state 
transformation. The control points of a program are defined by its atomic actions. Each atomic 
action has distinct entry and exit control points. For example, the atomic action that implements 
skip has a single entry control point and a single exit control point; the test for an if has one entry 
control point and multiple exit control points, one for each alternative. Execution of an atomic 
action a can occur only when an entry control point for a is active. Among other things, execution 
causes that active entry control point to become inactive and an exit control point of a to become 

active. 

For each command or atomic action 5, we define the following control predicates: 


at(S ): an entry control point for 5 is active. 

after (S): an exit control point from S is active. 

in(S): at(S') holds for some atomic action comprising S. 

The various commands of a programming language give rise to a set of axioms relating these 
control predicates. These axioms formalize how the control predicates for a command or atomic 
action 5 relate to the control predicates for constructs comprising 5 and constructs containing S, 
based on the control flow defined by S. For our programming language these axioms are given in 
Figure 1. We use GEval if (5) there to denote the guard evaluation action for an if with label 5 and 
GEvaWS) to denote the guard evaluation action for a do with label 5. Equality of Boolean values 
is logical equivalence. And, we write P 10 P 2 © • • • ®-P * to denote that exactly one of Pi through P n 

Our programming language is based on guarded commands [3]. Sequencing is written without 
the traditional semicolon separator. 3 The guard evaluation of the if command atomically evaluates 
all its tests at once and selects a branch for which the test is true; if none are true, then it will block 
until some test is made true by another process. A do command atomically evaluates its tests 
selects a branch with a true test, and repeats; if none are true, then it exits. A cobegin command 


2 More formally, we admit any interpretation in which a/b is interpreted as a divided by b when 6^0, and has 


arbitrary values otherwise. 

3 We shall later see that this avoids a problem. A semicolon separator would have to occupy 
an assertion in the standard textual representation of the proof outline. 


the same position as 
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starts all of its component processes simultaneously, executing them concurrently. When they all 
finish, the cobegin finishes as well. 



Construct 
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Figure 1: Control Predicate Axioms 


2.2 Syntax and Meaning of Proof Outlines 

A proof outline PO{S ) for a program or atomic action S is a mapping from the control predicates 
of S to assertions. Each assertion is a Predicate Logic formula in which -*■ 

• the free variables are program variables (typeset in italics) or rigid variables , (typeset in 
uppercase roman), and 

• the predicate symbols are control predicates or the predicates of the programming language’s 
expression language. 

Asserti ons in w hic h all terms a re constructed from program variables, rigid variables, and predicates 
involving those variables are called primitive assertions .' 

If T is a subprogram of S and some PO{S ) is fixed, then we write pre(T) (resp. post(T)) for the 
assertion(s) that PO(S ) associates with at(T) (resp. aftcr(T)); these are called the precondition 
and postcondition of T. For the proof outline in Figure 2, this correspondence is summarized in 
Figure 3. In it, x is a program variable and X is a rigid variable. All assertions except pre(5) and 
post(S') are primitive. 

Proof outlines are generally represented as texts containing the program 5 and an assertion in 
braces before and after every subprogram of S. For our programming language, this will associate 
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{x = XA at{S)} 

S: if x > 0 — ►{x = X Ax > 0} 

5j : skip 

{x = X A x > 0} 

Q x<0— >{x = XAx<0} 

5 2 : x := — x 
{-x = X A -x < 0} 
fl 


Figure 2: Computing |x| 

at least one assertion with every control predicate of a program. Multiple control predicates may 
be mapped to the same assertion, as illustrated by the proof outline 

{ P } X := 1 {Q} j/ := 2 {R}. (1) 

Here, the entry control point for program x 1 y := 2, and the entry control point for x := 1 map 
to the same assertion, P. This is reasonable, because at(“x := 1 y := 2”) and at( u x := 1”) are 
equivalent; if one control point is active, so will be the other. 

Finally, for a proof outline PO(S ), we write pre( PO(S)) to denote pre(S), post(P0(S)) to 
denote post(£), and use a triple {P} PO(S ) {Q} to specify the proof outline in which pre(S) is P, 
post(5) is Q , and all other pre- and postconditions are the same as in P0(5). 


Assertion 

Assertion Text 

pre(S) 

x = X A at(S) 

post(5) 

x = |X| A after(S) 

pre(Si) 

x = X A x > 0 

post(Si) 

x = X A x > 0 

pr e(S 2 ) 

x = X A x < 0 

post(S2) 

—x = X A —x < 0 


Figure 3: Assertions in a Proof Outline 


Validity of Proof Outlines 

The assertions in a proof outline are intended to document what can be expected to hold of 
the program state as execution proceeds. The proof outline of Figure 2, for example, implies that 
if execution is started at the beginning of S\ with x = 23 (a state that satisfies pre(5i)), then if 
Si completes, post(Si) will be satisfied by the resulting program state, as will post(S). And if 
execution is started at the beginning of S with x = X, then whatever assertion is next reached be 
it pre (Si) because X > 0 or pre(S 2 ) because X < 0— that assertion will hold when reached, and 
the next assertion will hold when it is reached, and so on. 

With this in mind, we define validity of assertions and proof outlines. A valid assertion P 
is one that holds in all program states, viz states satisfying the datatype and control predicate 
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{true} 

a: cobegin 

{* = 1 } 

b: skip 

(...) 

// 

(...) 

c : skip 

(...) 

coend 

(...) 


Figure 4: Multiple Active Control Points (Partial proof outline) 


axioms. A valid proof outline PO(S) will be one that describes a relationship among the program 
variables and control predicates of 5 that is invariant and, therefore, not falsified by execution of 
5. The invariant defined by a proof outline PO(S) is “if a control predicate cp is true, then so is 
every assertion that PO(S) associates with cp” and is formalized as the proof outline invariant for 
PO(S ): 

: f\{(at(T)^ P ve(T))A(after(T) => po 

T 

where T ranges over the subprograms of S. For example, the proof outline invariant defined by 
PO(S) of Figure 2 is: 

at(S ) =^(i = XA at(S )) A after(S) =$■ (x = |X| A after(S)) 

A a<(Si) (x = X A x > 0) A after(Si) =► (x = X A x > 0) 

A a<(S 2 ) =► (x = X A x < 0) A after(S 2 ) => (— x = X A -x < 0) 

Notice that proof outline validity is with respect to executions starting in any state, even a 

state in the middle of the program. For example, the proof outline 

(i = 0 A j/ = 1} 

5 : a : x := x + 2 

{x = 2} 
b : y := y + 2 

(i = 2 A j/ = 3} 

is not valid. This is because a state where at(b), x = 2, and y = 20 hold satisfies Ipo (s) , but 
starting execution in this state leads to one that does not satisfy Ipo(S)’ 

In order to make the inference rules of our logic as easy to use as possible, we have designed 
them so that hypotheses concerning proof outlines do not delve too deeply into the structure of 
those proof outlines. Allowing multiple control predicates to be true simultaneously - as we do - 
complicates the realization of this goal. Consider the concurrent program of Figure 4. There, at (a) 
is true iff both at(b) and at(c) are true. Thus, in Figure 4, if at(a) and Ipo(S) are both true, then 
x = 1 holds. However, pre(a) gives no warning of this requirement; it is the trivial assertion “true”. 
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To avoid such anomalies, we insist that a proof outline PO(S ) give its requirements in its 
precondition. If at(S ) and pre( PO(S)) hold, then Ipo(S) mus t hold as well. We call such proof 
outlines self-consistent, and require self-consistency of a valid proof outline along with invariance 

of Ipo(S)- 

These invariance and self-consistency requirements for proof outline validity can be formalized 
in terms of Wj-validity of Temporal Logic formulas, where H 5 contains all infinite state sequences 
constructed by executing programs C[S] that contain a copy of 5. The elements a of are those 
infinite sequences of states such that: 

» (Jo is a state reached by executing some program C[5] zero or more steps from its initial state, 
and 

• each state cri+i is a possible result of performing an atomic action of S from state <r,, or, if 
no action of S is enabled, repeating cr,-. 

Note that (= P denotes that a Predicate Logic formula P is valid, because every program 
state is the first state of some sequence in We now define PO(S) to be valid if and only if 


Invariance: f= Ipo(S) =*■ a ^P0(S) 

Self-Consistency: (= (at(S) A pre(S)) => Ipo(S) 

From this definition we see that values of rigid variables are the same throughout any execution, 
because free rigid variables in a temporal logic formula are implicitly universally quantified. This 
means that rigid variables in proof outlines can be used relate the values of program variables from 
one state to the next. For example, the proof outline of Figure 2 is valid and employs a rigid 
variable X to record the initial value of x. Starting execution in a state where af(S 2 ) and x = -23 
holds will satisfy Ipo(s) ^ ^Ipo(S) ®ven if X is 41 rather than — 23 because then Ipo(S) not 
satisfied (causing Ipo(S) Dj Tpo(S) be trivially satisfied). 

2.3 Axiomatization for a Proof Outline Logic 

Proof Outline Logic is an extension of Predicate Logic. The language of Predicate Logic is extended 
with proof outlines for all atomic actions, commands, and programs. The axioms and inference 
rules of Predicate Logic are extended with axioms and inference rules that allow only valid proof 
outlines to be proved theorems. In particular, there are some command-independent inference 
rules as well as an axiom or inference rule for each type of command and atomic action. The 
command-independent rules appear in Figure 5. With one minor exception, they will apply in our 
real-time setting as well. We now turn to the axiomatization for a guarded- command concurrent 
programming language. 

The skip command is a single atomic action whose execution has no effect on any program 
variable. Thus, it leaves primitive assertions — which only mention program variables and terms 
that by their nature cannot change — unchanged. 

skip Axiom: For a primitive assertion P: {P} skip {P} (7) 

The familiar Hoare [7] assignment rule applies: 
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Rule of Consequence: 


p'=»p, {p}pp(S){Qh Q^QL 

Jp 7 ) po(S) W) 


( 2 ) 


Rule of Equivalence: 

P0(S), Ipo(S) = IpO'(S) » pre(P0'(5)) A a<(5) => pre(PO(P)) ^ 

PO'(S) y ’ 


Rigid Variable Rule: PO(S)g xp denotes a proof outline in which rigid variable X in every 
assertion is replaced by Exp, an expression involving constants and rigid variables 
(only). 

(P) PO{S) {Q} 


{■^Exp} PO(S) Exp {<?Exp} 


(4) 


Conjunction Rule: PO a (S)<$POb(S) denotes the proof outline that associates assertion 
AcpABcp with each control predicate cp, where Xq, is the assertion that POx{S ) 
associates with control predicate cp. 


POa(S), POb(S) 
PO a (S)®POb(S) 


Disjunction Rule: PO A (^S')^) PO denotes the proof outline that associates i4cpV Pep 
with each control predicate cp. 

POa(S), POBjS) rfn 

P0 A (S)®P0 B (S ) K) 


Figure 5: Command-Independent Rules of Ordinary Proof Outline Logic 


Assignment Axiom: For a primitive assertion P: {Pf } x := c {P} (8) 

Sequential composition of commands is like Hoare’s rule without deletion of the intermediate 
assertion: 


Command Composition Rule: 

jp] Si {Qh io) s 2 m rq > 

{P}Si{Q}S t {R} 1 ' 

In order to reason about an if command, we must reason about its guard evaluation action as 
well as the commands it guards. The following axiom allows us to derive proof outlines for guard 
evaluation actions. 
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GEvaltf(S) Axiom: For an if command 

and a primitive assertion P, 

{P} GEvalif(S') {PA (A, at(Si) => P,)} (10) 

A proof outline for an if is then constructed by combining a proof outline for its guard evaluation 
action with a proof outline for each alternative. 

if rule: 

(а) {P} GEval;f(5) { R } 

(б) (R A at(Si)) => P u (i? A at(S n )) => P n 

(c) {Pi] POjSi) {Qh ...» {P n } POjSn) {Q} 

{P} 

S : ifBi-{Pi}PO(5i){Q} (11) 

|p n ^{p n }po(5„){g} 

fi 

{Q} 

The guard evaluation action for do selects a command S{ for which corresponding guard P, 
holds. If no guard is true, then the control point following the do becomes active. 


GEvaldoC^) Axiom: For a do command 

S : do 0 • ■ • D B n -+S n od 

and a primitive assertion P, 

{P} GEval do (5') {P A (A i ot(Si) => Bi ) A (after(S) =$■ (-'Pi A • ■ • A ->B n ))} (12) 


The inference rule for do is based on a loop invariant , an assertion I that holds before and after 
every iteration of a loop and, therefore, is guaranteed to hold when do terminates — no matter how 
many iterations occur. 

do rule: 

(a) {/} GEval do (5) {R} 

(b) (PA at(S x ))=> P u (R A at(S n )) => P n 

(c) {P X } PO(Sx) {/}, .... {Pn} PO(S n ) {/} 

( d ) ( R A after{S) ) =>■ (/ A ->Pi A • • • A -iP n j 


5: doP x -{P 1 }P0(5 1 ){/} 

0 ... 

%B n ^{P n }PO(S n ){I} 

od 

{/ A ->Px A • ■ • A “’Pn} 
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The inference rule for a cobegin combines proof outlines for its component processes. An 
interference- freedom test [12] ensures that execution of an atomic action in one process does not 
invalidate the proof outline invariant for another. This interference-freedom test is formulated in 
terms of triples, 

A r /(a, A): (pre(a) A A} a { A } 

that are valid if and only if or does not invalidate assertion A . If no assertion in PO{Si ) is invalidated 
by an atomic action a then, by definition, Ipo(s t ) a l s0 cannot be invalidated by a. Therefore, we can 
prove that a collection of proof outlines PO(Si) } PO(S n ) are interference free by establishing. 

Interference Freedom (14) 

For all z, j, 1 < i < n, 1 < j < n, i ^ j : 

For all atomic actions a in 5; : 

For all assertions A in PO(Sj) : 
i V/(a, A) is valid. 

The following inference rule characterizes when a valid proof outline for a cobegin will result 
from combining valid proof outlines for its component processes: 

cobegin rule: 

(a) PO{S x ), PO(S n ) 

(b) P => (A, pre(PO(Si))) 

(c) (A, post(PO(S<))) (15) 

(d) PO(Si ), . . . , PO(S n ) are interference free 
{P} cobegin PO(Si)// ■ • • // PO{S n ) coend {(?} 

Since execution of an atomic action a in one process never interferes with a control predicate 
cp in another, certain interference-freedom triples follow axiomatically. 

Process Independence Axiom: For a control predicate cp in one process and an atomic 
action a in another, 

{cp = X} a {cp = X} (16) 

Notice that NI(a, cp) follows directly from this axiom when a and cp are from different processes. 

2.4 From Proof Outlines to Safety Properties 

Theorems of Proof OutUne Logic can be used in verifying safety properties because of the way that 
proof outline validity is defined. If a proof outline PO{S) is valid then Ipo(S) must be an invariant. 
Suppose that Ipo(S) is an invariant. Then according to the method of Section 1 for proving safety 
properties, we can prove that executions of S starting with pre( PO(S)) true will satisfy the safety 
property proscribing -> Q by proving (at(.S') A pre(PO(S'))) => Ipo(s) an< ^ ?PO(S) ^ The proof 
of (at(5) A prePO(S)) =s> Ipo(S) follows trivially from the way Tpo(S) is defined. And, to prove 
Ipo(S) => we simply prove 

(cpAAcp)=>Q (17) 

for every assertion A cp in PO{S), where A cp is the assertion that PO(S) associates with control 
predicate cp. For example, we prove as follows that for she absolute value program in Figure 2 
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after(S) ^ (x = |X|) holds during executions started in a state satisfying x = X A at(S ): For the 
case where cp does not imply after(S), (17) is trivially valid. The remaining cases are when cp is 
after(S\), after(S 2 ) and after(S). Here, we must show 


All are valid. 


after(Si) A post(5i) 
after(S2) A post(5'2) =i> 

after(S) A post(5) => 


(after(S) => (x = |x|)) 
(after(S) (x = |x|)) 
(after(S) =► (x = |x|)) 


3 Real-time Logic 

3.1 A View of Real Time 

In taking into account real-time, our universe of discourse comprises processes executing parts of 
some program along with an external world. We thus are forced to consider three kinds of actions: 

Ordinary actions: Atomic actions without timing constraints are called ordinary actions. They 
may execute whenever they are enabled, or wait arbitrarily long. 

Real-time actions: A real-time action is an atomic action whose execution time is constrained. 

Idles: Execution time may pass without the program doing anything. Such a passage of time can 
be attributed to the external world, and we model this by an idle . 

Ordinary actions are familiar, and the Proof Outline Logic of Section 2 works fine for them. 
Real-time actions cause no logical difficulties, as they have the same effects on variables and program 
state as ordinary actions, but their execution is more constrained. Adding axioms to Proof Outline 
Logic suffices for reasoning about the execution time of real-time actions. Idles, strangely enough, 
are more troublesome because their presence causes some matters of logical concern (viz., the time) 
to change without program execution. For example, Rule of Consequence (2) is unsound when idles 
are present. 

In defining our logic, we consider an extremely powerful real-time language, allowing constructs 
that may be impractical or impossible to implement. Programmers using actual languages will 
not necessarily have access to all the features we allow. However, we believe that most actual 
programs in our intended domain can be translated into our language. Thus, expressive power is 
an advantage: the more powerful our language, the greater the number of real programs that can 
be expressed in it. 

Our programming language is the one of Section 2 with additional real-time actions. In particu- 
lar, for each unconditional atomic action 4 a, we define corresponding real-time action (a)^ where 
6 and e are real-valued, non-negative constants. Execution of (a)^ e j causes the same indivisible 
state transformation as a does, but constrains it to occur at some instant between c and e + 6 time 
units after the entry control point for (a)^ e j becomes active. 

We have elected to characterize the execution time for a real-time action in terms of two parame- 
ters (6 and c), following [14], in order to gain flexibility in modelling various execution environments. 

4 An atomic action is unconditional if it is executable whenever its entry control point becomes active. In the 
programming notation of Section 2, skip, assignment, and the guard evaluation action for do are unconditional. The 
guard evaluation for if is not unconditional. 
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Parameter e describes the fixed execution time of the action on a bare machine; S models execu- 
tion delays attributable to multiprogramming and other resource contention. A system where each 
process is assigned its own processor is modeled by choosing 0 for 6 ; a system where processors are 
shared is modeled by choosing a value for S based on the length of time that a runnable process 
might have to wait for a processor to become available. 

As an illustration, suppose we know that assignment commands take one time-unit, and that 
there is a single processor. If three assignment commands are started concurrently, they will be 
executed in some order. The first one to run will be started immediately and take one time-unit; 
the last one will be started two units after it was issued, and it also takes one time-unit. Thus we 
could model this with real-time actions having an execution time of 1 and a possible delay of 2. 

cobegin (xl := : = 2 )[ 2 , i ]^( x3 := 3 )[ 2 , i ] coend 

We do not allow a in a real-time action to be a conditional atomic action, such as an 

if guard evaluation action, because it is not clear what such a construct would mean. The delay 
in a conditional atomic action is already dependent on something else - changes to the program 
state. Lower bounds on conditional atomic actions (e.jf., an if command that requires at least one 
time- unit to evaluate its condition) can be implemented with a real-time skip command followed by 
an ordinary if. Timeouts on conditional atomic actions can be implemented by parallel processes 
and shared variables. 

When writing a real-time program, it is sometimes necessary to program a loop whose iterations 
have fixed or bounded execution time. All of the atomic actions in such a loop must be real-time 
actions. We therefore introduce the following syntax to specify that (GEvabjo^))^] be used as 
the guard evaluation action in a do command: 

do[s t t]Bi-+Sx Q ■ ■ • 0 5 n — ►Snod (18) 


3.2 Reasoning About Real-time Actions 

To reason about timing properties, terms are added to the assertion language and additional in- 
formation is included in the program state. This is because the method of Section 2 for reasoning 
about safety properties can only be used to prove safety properties for which the negation of the 
proscribed -> Q is implied by each of a proof outline’s assertions. Timing properties, by definition, 
concern the instants at which control predicates become active, so we define a term ]cp for each 
control predicate cp : 


T cp = 


( 


t 

-00 


t is tlxe time that cp last became true 
cp has never been true 


(19) 


We also define a new real- valued term T to be equal to the current time. 

Only certain assignments of values to these terms are sensible in a program state. In particular, 
if two control points become active as part of the same event, then they must be assigned the same 
time. For example, since S is the first subcommand of S T, we require that fat(.S') = T). 

Similarly, the subcommands Si and S 2 in S: cobegin S 1 //S 2 coend start at the same time, so 

we require faf(Si) = ta^S^) = T a<(S). 

Notice what effect adding these terms to the state has on the definition of proof outline validity. 
Recall that a proof outline P0(S) is valid if execution starting in any state that satisfies Ipo(S) 
leaves I P0 (5) invariant. Now, a state includes a time, and so we must consider starting states with 
arbitrary times as well as arbitrary values for program variables and control. 
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Let C[S] be a program containing a copy of S. An initial state of C[S] not only must satisfy 
a<(C[S]), but must be one in which the value of T is some non-negative number, and the values 
of ]at{T ) and |a//er(T) (for every command T) are initialized properly. That is, for any control 
predicate cp, if at(C[5])=i> cp is valid, then f cp has the same value as T; otherwise it is -oo. The 
elements a of “Hg are those infinite sequences of states such that: 

• <7 0 is a state reached by executing some program C[S\ zero or more steps from an initial state, 
updating T, f at(T), and f after(T) appropriately on each step. 

• Each state <r, +1 is the result of performing an ordinary action, a real-time action, or an idle 
from ct,-. Execution of an ordinary or real-time action updates T, |at(T), and | after(T) 
appropriately. Execution of an idle only updates T , and in a way that does not violate the 
bounds 6 and e associated with any enabled real-time action. If no action of S is enabled, 
then the only transition permitted is an idle that does not increase T. 

Validity of proof outlines in our real-time logic is defined as before (Section 2.2), using Tig in 
place of Tig : 


Real-Time Invariance: 


Ws t= 1 ‘ 


PO(S) 




PO(S) 


( 20 ) 


Real-Time Self-Consistency: TfJ ( at(S ) A pre(£)) => Ipo(S) 

Axioms and Rules for Real Time 

Execution of a real-time action (a)^ e j affects the program variables and control predicates in 
the same ways as the ordinary action a from which it was derived. Therefore, we have the following 
inference rule: 

Real-time Action Transformation: For a an unconditional atomic action, P and Q 
primitive assertions, and 0 < 6 and 0 < e: 

a m 

( q )[m { Q ) 




Some additional axioms and inference rule allow us to reason about formulas of our more ex- 
pressive assertion language. First, the various non-atomic commands of our programming language 
give rise to axioms based on the way they equate their components’ control points. These axioms 
are similar to the control-predicate axioms. For our programming language, these axioms are given 
in Figure 6. 

Next, there are the additional axioms given in Figure 7 for the assertion language. In these, cp 
can denote any control predicate, including those not associated with entry or exit control points for 
real-time actions; S is the label for a real-time action (a)p #c j. Axioms (22) and (23) follow directly 
from the definition of ]cp. Axioms (24) and (25) capture the essence of a real-time action — that 
its entry control point cannot stay active too long. This, in turn, allows us to infer that a control 
point is not active by using the following corollary of (24): 

(T at(S) + 6 + e < T) => - at(S) (26) 


13 


For 5 the sequential composition SjS 2 

M 5 ) 

| after(S) 

t after (Si) = 

^at(Si) 

fa/(er(S 2 ) 

tat(S 2 ) 

For an if command: 

5: if Bi-*S\ fl 

...|J? n -S n fl 

MS) 

ta<(GEvaJ if (S)) 

T after(S) 

max(tq/fer(Si), ... , | after(S n )) 

fa/<er(GEvalif(S)) = 

max(|a<(Si), ... ,|at(S n )) 

For a do command: 

S : doi?x-+Si[] 

••• U B n —*S n od 

ta<(GEval<i 0 (S)) = 

max(]at(S),'\after(Si ), . . .,'\after(S n )) 

ta/fer(GEvaldo(S)) = 

max(T after(S), Taf(Si), . . ]at(S n )) 

-’in(S) =£■ 

t after(S) = Ta/ter(GEvaldo(S)) 

at(S ) =>• 

faf(S) = ta*(GEvaldo(S)) 

in(Si) => 

|a<(Si) = | a/ter(GEvald 0 (S)) 

after(S) => 

jafter(Si) = t«<(GEvald 0 (S)) 

For a cobegin command: 

S : cobegin Si/f •••//S n coend 

MS) 

MSi) = Tat(S 2 ) = --- = MSn) 

'\after(S) = 

max ('l after (Si), ... , t a/fer(S n )) 


Figure 6: Control Time Axioms 


The way these new terms change value when atomic actions execute is captured by new axioms. 
For any ordinary or real-time atomic action a and control predicate cp, we have: 

cp Invariance { cp = C A |cp = V} a {(cp =» C) ^ (UP = V)} (27) 

The antecedent in the postcondition is necessary for the case where cp could become true when a 
finishes, e.g., cp = aftcr(a). 

Next, for any ordinary action, we have: 

Action Time Axioms: 

{K < fat(S)} S: a {K < |a/ter(S)} (28) 

{K < T) S: a {K < Ufter(S)} (29) 

Action Time Axiom (28) asserts that the exit control point for S becomes active after the entry 
control point for 5 last became active. Action-time Axiom (29) makes the subtly different assertion 


Up 

< 

T 

(22) 

(T cp = -00) 

=> 

—icp 

(23) 

at(S) 


MS) <t <ut(S) + s + c 

(24) 

faf(S) 7^ —00 


|a/iter(S) < S) + ^ c 

(25) 


Figure 7: General Real-Time Axioms 
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that the exit control point for S becomes active after every time that the entry control point for S 
was active. 

For a real-time action (a)^ e j, the following axiom characterizes how execution changes the 
]cp- terms. 

Real-time Action Axiom {K < fat(S)} S : (o)^] {K + c < T after(S)} (30) 

This axiom is analogous to Action-time Axiom (28), except that now the postcondition has been 
strengthened to give a tighter lower-bound on when the exit control point for S first becomes active. 

Two things that the Real-time Action Axiom (30) does not say are worthy of note. First, this 
axiom does not bound the interval during which the entry control point for 5 is active; Axiom (24) 
serves that role. Second, one might expect the following triple to be valid— its precondition being 
similar to that of (29). 


{K < T} 5: (a) [M {K + <r < T} (invalid) (31) 

Unfortunately, (31) is not sound. Execution of 5 started in a state such that | at(a) < K < T would 
satisfy the precondition but might terminate before K + c. For example, consider an execution of 
(a) (02] that is started at time 0. Thus, at time T = 1 the state satisfies K < T if we choose K = 1, 
and so precondition K < T is satisfied by that state. When execution of (q)jo,2] terminates 2 
units after it is started — at time T = 2, the postcondition K + e < T is 1 + 2 < 2, which is false. 

Finally, the following rule allows rigid variables to be instantiated with expressions involving 
| cp- terms. (Rigid Variable Rule (4) only allows rigid variables to be instantiated by constants, 
rigid variables, or expressions constructed from these.) 


{ ]cp = V} a {\cp = V), {P} a {Q} 

Tcp-Instantiation |pX J ~ |qX j 


(32) 


This rule is typically used along with cp Invariance (27). For the case where real-time action 
a and control predicate cp are in different processes, the first hypothesis of |cp-Instantiation is 
automatically satisfied due to Process Independence Axioms (16). Thus, we obtain a derived rule 
of inference: 


a and cp are in different processes, 
Derived fcp-Instantiation {P} a {Q} 


(33) 


3.3 Rule of Consequence Revisited 

Most of the axioms and proof rules of Proof Outline Logic are sound in our real-time setting. 
However, the Rule of Consequence (2) is unsound and needs revision. We also need to revise 
the notion of interference freedom. While the Owicki-Gries cobegin rule [12] is sound, when the 
assertion language concerns real time, the rule is is no longer complete and, in particular, not 
powerful enough for even simple examples of concurrent real-time programs. 

Rule of Consequence (2) is invalid in any setting where some aspect of the state is not under 
program control. Recall, the rule is: 
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Maxldle(a) 

MaxIdle(<a) [M ) 

Maxldle(5i5 , 2) 

Maxldle(if ■ ■ - fi) 

MaxIdle(do • • -od) 

MaxIdle(do[5 j£ ] • ■ - od) 
MaxIdle(cobegin5i/ • • -^5 n coend) 


= oo a ordinary 

= 6 4- e 
= Maxldle(5i) 

= oo 
= oo 
= 6 + e 

= min {Maxldle(5',)|t = 1, . . . , n} 


Figure 8: Definition of MaxIdle(S), the maximum idle of S 


g ± P, {P} POjS) {Qh Q_±Qj 

W\ po(s) m 

The difficulty is illustrated by the following example. Consider the following proof outline, which 
is valid in our model: 

{T > 4} S : skip {true} (34) 

Furthermore, note that 

(T = 4) =► (T > 4) (35) 

is valid. However, if we apply the Rule of Consequence to (34) and (35), we obtain the following 
proof outline: 

{T = 4} 5: skip {true} (36) 

It is invalid because an idle by the environment invalidates its precondition, T = 4. In particular, 
let 7 be a state in which at(S ) A T = 4 is true. Therefore, the precondition of (36) is satisfied by 
7, and so is Ipo(S)- An idle can lead to a state 7' in which at(5') A T = 4.01, invalidating Ipo(S)- 
Thus the proof outline does not satisfy Real-Time Invariance (20), and hence is not valid. 

We eliminate problems of this sort by modifying Rule of Consequence (2) so that idles cannot 
invalidate a strengthened precondition P' . In light of (36), an obvious approach is to rule out any 
strengthening of preconditions achieved by placing an upper bound on T. However, that restriction 
would prevent us from deriving the valid triple 

{f at(S) = 4A4<T<6)5: skip [0i2 ] {true}. (37) 

We therefore characterize the interval over which a strengthened precondition P' must not be 
invalidated by an idle. For any program 5, define Maxldle(. : 'i (maximum idle time for S ) to be the 
longest real time interval that can elapse after at(S ) becomes true but before some program action 
of S must be executed. If S may idle arbitrarily long, then MaxIdle(S) = 00. Figure 8 gives a way 
to calculate Maxldle(5) by induction on the structure of S. 

For example, 

Maxldle(skip) = 00 
as skip can wait arbitrarily long before taking a step, and 

MaxIdle(cobegin skip/(skip)[ 0 2 .. coend) = 2 
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as that program will necessarily take a step at or before time 2. In order for Rule of Consequence 
(2) to be sound, not only must P f =>P hold but P* must remain true until time ta*(S) + MaxIdle(S). 
We say that an assertion P is patient for S if 

(P A at(S )) => (W.(T < d < t at(S) + Maxldle(5)) =► Pj) (38) 

Thus, if P' is patient for S , then P' can be a precondition for S and no idle by S can invalidate 
P'. For example, 4 < T < 6 is patient for (skip)j 0 2 j, but 4 < T < 5 is not. A corollary of the way 
T-Cg is constructed is that the precondition of any valid proof outline PO(S ) is patient for S. 

Note that under some circumstances P' is easily demonstrated to be patient for S : 

• If P' does not mention T. 

• If P' only gives lower bounds on T. 

However, even assertions involving upper bounds on 7* can be patient. For example, 

]at(S) = 4 A 4 < T < 6 


is patient for 5 : skip | 0 2 i. 

A sound Rule of Consequence for our real-time logic can be formulated in terms of patient 
assertions: 


Rule of Consequence: 

P' ^ P, P' is patient for 5, {P} PO(S) {Q}, Q => Q' 

IF] PO(S ) {Q 7 } ^ ; 

So, because T = 4 is not patient for skip, it is not possible to deduce (36) from (34) and (35) 
using this new Rule of Consequence. On the other hand, because 

(t at(S) = 4 A 4<T <6)=>T>4 (40) 

is valid and | at(S) = 4 A 4 < T <6 is patient for skip[ 0>2 ], we can use the Rule of Consequence 
(39) to infer 

{|at(5) = 4 A 4<T<6} skip[ 02 j {true} (41) 

Note that we do not need to place similar restrictions on Q'. The interpretation of {P} PO(S ) {Q} 
is that, when 5 finishes, Q remains true indefinitely. If Q =» Q' in predicate logic, and Q remains 
true forever, then Q' will also remain true forever. 

The following derived rule, the Simple Rule of Consequence, handles most of the bookkeeping 
uses of the Rule of Consequence (39): 

_ P' = P, {P}PO(S){Q}, Q=>Q' 

Simple Rule of Consequence {p 7 } PO(S) [Q' ] 
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3.4 Interference Freedom Revisited 

When execution times of atomic actions are bounded, certain forms of interference cannot occur. 
This is illustrated by the following proof outline. 

{* = 0 } 

cobegin 

{x = 0} a: (x := x + 1) (0 , 2 ] {* = 1} 

// 

{x = 0} /3: (y:=x + 1) [01] {y = 1} 

coend 

{x = 1 A y = 1} 

It is valid, but cannot be derived using the cobegin Rule because PO(a ) and PO{(3) are not 
interference free. In particular, NI(a, pre(/?)) is not valid. 


jV7(a,pre(/?)) 

= {pre(a) A pre(/3)} (x := x + l)f 0 2 ] (pre(/?)} 

= {a: = 0} (x := x + l) [02l {x = 0} 

Using operational reasoning, however, it is not difficult to see that executing a cannot invalidate 
pre(/3), so PO(a) and PO(fi) should be considered interference free. This is because according to 
Figure 6, both at(a) and at((3 ) become active at the same instant, say time 0. By definition, o 
completes at time 2, and so x remains 0 until this time. Real-time action (3 completes at time 1 
and, therefore, must find x to be 0. Thus, it is simply not possible for a to change the value of x 
while o/(/3) is active. 

The ordinary cobegin Rule (15) is based on a form of interference freedom that does not take 
into account execution- time bounds of real-time actions. In particular, NI(a, A cp ) does not account 
for the fact that although A cp might be associated with an active control point cp when a is started 
then we may be able to prove that cp cannot be active when a completes. The remedy is to refine 
NI(a, Acp) taking into account the time bounds for how long an entry control point for a real-time 
action can remain active. The following triple accomplishes this. 5 

NI rt (a, Acp) : {of(a) A pre(a) A cp A A^} a{cp=^Acp) 

Returning to the example above, we now have: 


NI rt (a, pre(/?)) 

= (a*(a) A pre(a) A at((3) A pre(/3)} (x := x + 1 )j 0 2 j => pre(/3)} 

= (a<(a) A at(fi) A x = 0} (x x + 1)[ 0>2 ] { <*<(/?) => x = 0} 

And, this obligation can be discharged as follows. We present the proof in detail, to show how 
the axioms and rules fit together. Steps that involve standard logic (including arithmetic) are listed 
as simply “predicate logic.” 

5 This triple is not specific to real time; see [11] for example. It arises naturally when one attempts to construct a 
proof rule for cobegin. In many cases, it can be simplified to the Owicki-Gries condition, but here it cannot. 
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ORI&MAL FACiE IS 

OF POOR QUALITY 


1. Real-time Action Axiom (30) 

(K<To<(a)} a: (x := x + 1> [02) (K + 2 < Ufter(a)} 

2. Derived jcp-lnstantiation (33) with 1, substituting |af(/?)for K 

{)«<(/?) < Tai(a)} a: (x := x + 1) [0>2] {Ta<(/?) + 2<! after(a)} 

3. Axiom (22) with ]after(a) for |cp, and predicate logic 
(faf(/3) + 2 < T after(a)) =}► (t at(fl) + 2<T) 


4. Simple Rule of Consequence, (42) with 2 and 3 

< Taf(a)} a: (x := x + 1) [M {]at((3) + 2 < T} 

5. Axiom (24) and predicate logic 

at(/3) =* t at(0) <T< + 1 


6. Predicate logic and arithmetic: 

(a<(/3) =* UK0) <T< T at((3) + 1) =* ((|at(/3) + 2 < T) =» -a<(/?)) 


7. Modus Ponens from 5 and 6 

(t at(/3) + 2 < T) => ->at(0) 


8. Simple Rule of Consequence with 4 and 7 

{Tat(/3) < taf(a)} a : (x :=x + 1)[ 0>2 ] {--ai(/3)} 

9. A Control Time Axiom from Figure 6 

Ta*(a) = Ta*(/3) 


10. Predicate logic from 9 

t at{P) < |a<(a) 


11. Predicate logic from 10, since anything implies true 

pre(A7 rt (a,pre(/?))) =* ]at((3) < T at(a) 


12. Predicate logic 

->at(/3) =>■ post(NI r t(a, pre(/?))) 

13. Rule of Consequence with 8, 11, and 12; patience is vacuous 

A7 rt (a,pre(/3)) 
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Notice that information about the time after a is accumulated in steps 4 and 5, and used in 
step 6 to reach the same conclusion that operational reasoning gave: that, once a finishes, j3 has 
also finished. 

4 Example: A Mutual Exclusion Protocol 

cobegin 

6 : if x = 0 — ► c: (x := l) (5 ( c ), e(c )] A 
d : (skip) { ^ )i<(d)] 

e : if x = 1 — ► /: Critical Section fi 

// 

6' : if x = 0 — ► c': (x := 2)^ ^ fi 

d ' : (skip)^,) ^,)] 

e ' : if x = 2 — * /': Critical Section fi 

coend 


Figure 9: Core of Fischer’s Mutex Protocol 

Knowledge of execution times can be exploited to synchronize processes. A mutual exclusion 
protocol attributed in [10] to Mike Fischer [4] illustrates this point. The core of this protocol 
appears in Figure 9. There, c, d, c' and d' are real-time actions. Provided the parameters defining 
these real-time actions satisfy 


S(c') + e(c') < e(d) 

(43) 

6(c) + t(c) < c(d') 

(44) 


this protocol implements mutual exclusion of the marked critical sections, as we now show. 

Mutual exclusion of at(f) and at(f') is a safety property. It can be proved by constructing a 
valid proof outline in which pre(/) ^ -'at(f') and pre(/ 7 ) =► ->at(f). A standard approach for this 
is to construct a valid proof outline in which ->(pre(/) A pre( f')) is valid. It is thus impossible for 
at(f ) A at(f') to hold, because that would imply pre(/) A pre(/'). 

A proof outline for the first process is given in Figure 10; the proof outline for the other process is 
symmetric, with “1” everywhere replaced by “2” and the primed labels interchanged with unprimed 
ones. Notice that pre(/)=>x = 1 and pre(/')^x = 2. Thus, the proof outlines satisfy the conditions 
just outlined for ensuring that states satisfying at(f) A at(f > ) cannot occur. 

It is not difficult to derive the proof outline of Figure 10 using the axiomatization of real- 
time actions given above. The proofs of {pre(c)} c {post(c)} and (pre(d)} d (post(d)} are the 
most enlightening, as they expose the role of assumptions (43) and (44) in the correctness of the 
protocol. Here is the proof of (pre(c)} c (post(c)}: 

Let 

M = S(c') + c(c') - c(d) 


1. Axiom (29) 

{K < 7} c: (i := % Wl<(c) , {K < Ufter(c)} 
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{true} 

6: if* = 0 - {Ta<(cO < T) 

c: (x := l)p( c ) it ( c )] 

{x ^ 0 A ( at(c ') =7- }at(c') + M < }at(d))} 

fi 

{x ^ 0 A (a<(c') => Tat(c') + M < {at(d))} 
d : <skip)j 5 ( ti ) c ( d )] 

(i ^ 0 A ->at(c , )j 

e: if x = 1 — ► {x = 1 A ->at(c')} 

/: Critical Section 1 

{true} 
fl 

{true} 

Figure 10: Proof Outline for Fischer’s Algorithm 

2. Derived |cp- Instantiation, (33), on step 1, to substitute T<*<(c0 f° r K 
{T^(c') < T} c: (x := % (c))<(c )] {Me') < \after{c )} 

3. Control Time Axiom (Figure 6) for if and sequencing 

]after(c ) = {o<(<0 

4. Predicate logic on step 3, and M < 0 by (43) 

(jatfc') < ]after{c )) => (|at(c') + M < }at(d)) 


5. Predicate logic on step 4 

fat(c') < ^afterfc) => (at(c') => (}at(c') + M < |at(d))) 

6. Simple Rule of Consequence (39) on steps 2 and 5 

{Tfl^c') < T) c: ( x := l> [5 ( c ), e ( c )] Me') =* ('M(c') + M < T <**(<*))} 

7. Assignment Axiom (8) 

{1 = 1} c: ( x := l) [5(c)it(c)] {* = 1} 

8. Predicate logic 
true =>(1 = 1) 


9. Predicate logic 
x = 1 => x 7^ 0 
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10. Rule of Consequence, (39) on steps 7, 8, and 9, since true is patient for c. 

{true} c: (x := % (c)t£ ( c)] {* # 0} 

11. Conjunction Rule (5) on steps 10 and 6, plus a trivial use of the Rule of Equivalence (3). 

{ } at(c') < 7"} c: (x l)[^( c ) <e ( c )] i x ^ ® ^ ^ T a H c ) + M < jat(d)) } 


And, here is the proof of {pre(d)} d {post(d)}. 

1. Real-time Action Axiom (30) 

{K < }at(d)} d: (skip)j^j {K + ((d) < ]after(d)} 

2. skip Axiom (7) 

{L < K} d: (skip) [5(J) e(rf)] {L < K} 

3. Conjunction rule (5) on steps 1 and 2 

{L < K A K < t at(d)} d: <skip) [5((i)it((i)] {L < K A K + ((d) < }after(d)} 

4. Predicate logic 

(L < K A (K + e(d) < | after(d))) =* (L + ((d) < ]after(d)) 

5. Rule of Consequence (39) on 3 and 4, noting that the precondition does not mention time and is 
thus patient. 

{L < K < T<<0} d ■ <skip> [5(<i ) iC ( rf )] {L + ((d) < T after(d)} 

6. cp Invariance axiom, (27) 

{at(d) = C A )at(d) = V} d: (skip)^^ {(at(d) =► C) =» (t a<(rf) = V)} 

7. Rigid Variable Rule (4) on 6, replacing C by true 

{at(d) = true A |a<(d) = V} d: <skip> [5(£f)tC(tf) ] {(at(<f) =► true) =>• (|at(d) = V)} 

8. Rule of Equivalence (3) on 7 

{T at(d) = V} d : {skip) [s(d) £((i)] {t at(d) = V} 

9. fcp-lnstantiation (32) using 8 and 5 to substitute |at(d) for K. 

{L < \at(d) < ta<(^)} d - ( ski P)[«(<i), £ (d)] ( L + € ( d ) < T after(d)} 

10. Rule of Equivalence (3) on 9 

{L < Ta*(<0} d: ( ski P)[«(<i) l£ (<f)] ( L + f ( d ) < T after(d)} 
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11. Derived fcp-lnstantiation (33), and Rigid Variable Rule (4), to substitute ]at(c') + M for L in 10 

{tat(c') + M < |a<(«0} d : (skip) [5(d)f(rf)] {ta<(c') + M + c(d) < }after{d)} 

12. Process Independence Axiom (16), Rigid Variable Rule (4), and Rule of Equivalence (3) 

(-at(c')} d: (skip) [i(d)ie((0] {-a<(c')} 

13. Disjunction rule (6) on steps 11 and 12 

{-ia<(c') V (ta<(c') + M < | ai(cf)) } d: (skip) [#((i)i£((i)] {-<at(c') V (Tat(c') + M + e(d) < j after {d))} 

14. Rule of Equivalence (3) on 13 

(at(c') =* (T at(c') + M < Ta<( rf ))} d: (skip) [5(<i)i£(rf) ] {->at(c') V (T<J<(c') + M + e(d) < j after(d))} 

15. Axiom (22) 

]after(d) < T 

16. 

-iat(c') V | at(c') + e(c') + 6(c') < }after{d ) 

=$> Predicate Logic from step 15 
~>at(c') V (ta<(c') + e(c') + 6(c f ) < T) 

=S> Equation (26) 

->at(c') V -i at(c') 

=» Predicate Logic 

-uit(c') 

17. Simple Rule of Consequence (42) on steps 14 and 16 

{<**(0 =► (Taf(c') + M < T at(d))} d: (skip) [5(d) e(d)] {--af(c')} 

18. skip Axiom (7) 

{* ^ 0} d: (skip) [5(ll)(£((i)] {z ^ 0} 

19. Conjunction Rule (5) on steps 18 and 17 

{* / 0 A (at(c') =► (| at(c') + M < !«*(<*)))} d: (skip) [i(<f) e(rf)] {x ± 0 A -^at(c’)} 

Notice how timing information is used in step 16 to infer that a particular control point cannot 
be active. 

5 Related Work 

It is instructive to compare our logic with that of [17], another Hoare-style logic [7] for reasoning 
about execution of real-time programs. In [17], the passage of time is modeled by augmenting each 
atomic action with an assignment to an interval- valued variable RT, so that RT contains lower and 
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upper bounds for the program’s elapsed execution time. The equivalent of our Command Composi- 
tion Rule (9) and the Assignment Axiom (8) would then be used to derive rules for reasoning about 
these augmented atomic actions. 6 In contrast, our logic is obtained by augmenting the assertion 
language (of an underlying logic of proof outlines) with additional terms (| cp and T) and devising 
new axioms for reasoning about these terms. We cannot derive rules for real-time actions simply 
by using the original logic, because we do not employ assignment commands to model the passage 
of time. 

Although our logic is more complex, by augmenting the axioms rather than the atomic actions 
we are led to a more powerful logic. First, having the fcp-terms allows the logic to be more expres- 
sive. These terms permit the definition of properties involving historical information information 
that is not part of the current state of the program. Timing properties that constrain the elapsed 
time between events can only be formulated in terms of such historical information. The logic of 
[17] has no way to express historical information and, consequently, can be employed to reason 
about only certain timing properties. 

Second, our axiomatization allows reasoning about programs whose timing behavior is data- 
dependent. The logic of [17] does not permit such reasoning. For example, because of the way 
command composition is handled in [17], the logic produces overly-conservative intervals for time 
bounds. This is illustrated by the following sequential program, which takes at least 10 time units 
to execute. 

if B -*■ skip [ 0 9 ] |] ->B -> skipj 01 ]fi 
if ~>B — skip [ 0 9 ] [j B -► skip [ 0 jjfi 

This fact can be proved in our logic; the logic of [17] can prove only that execution requires at 
least 18 time units. 

A Hoare-style programming logic for reasoning about real-time is also discussed in [8]. That 
work is incomparable to ours. First, the programming language axiomatized in [8] is different, 
having synchronous message-passing and no shared variables. This is symptomatic of a fundamental 
difference in the two approaches. The emphasis in [8] is on the design of compositional proof 
systems. Shared variables could not be handled compositionally and so they are excluded from 
programs. In contrast, we do not require that our proof system be compositional, and we do 
handle shared variables. 7 Moreover, it would not be difficult to extend our logic for reasoning (non- 
compositionally) about programs that employ synchronous message-passing or any of the other 
communication/synchronization mechanisms for which Hoare-style axioms have been proposed. 

The set of properties handled in [8] is also incomparable to what can be proved using our 
logic. Our timing properties make visible the times at which control points become active (through 
fcp-terms). A compositional proof system cannot include information about control points in its 
formulas, because they betray the internal structure of a component. The logic of [8], therefore, may 
only be concerned with times at which externally visible events occur: the time of communications 
events and the time that program execution starts and terminates. This turns out to allow proofs 
of certain liveness properties as well as certain safety properties. Our logic cannot be used to prove 
any liveness properties other than those implied by the progress of time. 

e The idea of augmenting actions with assignment commands in order to reason about the passage of time is also 
discussed in [5], where it is used to extend Dijkstra’s wp [3] for reasoning about elapsed execution time. A more 
recent effort to augment a wp calculus for real time is reported in [16]. 

7 The cobegin Rule of Proof Outline Logic (15) is not compositional because its interference-freedom test depends 
on the internal structure of the processes being composed. 
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6 Concerns 


A concern when designing a logic is expressive completeness. Our timing properties include many, 
but not all, safety properties of interest for reasoning about the behavior of real-time programs. 
This is because the historical information in a timing property is limited to times that control points 
become active. One might also be concerned with the elapsed time since the program variables last 
satisfied a given predicate or with satisfying constraints about how the program variables change 
over time. These are safety properties, but neither is a timing property (according to our definition). 
In general, safety properties can be partitioned into invariance properties and history properties 
[15]. The invariant used in proving an invariance property need only refer to the current state; the 
invariant used in proving a history property may need to refer to the sequence of states up to the 
current state. Timing properties are a type of history property. 

A version of Proof Outline Logic does exist for reasoning about history properties [15]. It 
extends ordinary Proof Outline Logic by augmenting the assertion language with a “past state” 
operator and a function-definition facility. In this logic, our Tcp-terms can be constructed explicitly; 
they need not be primitive. And, the more general class of safety properties involving times — be it 
times that predicates hold or times that control predicates hold — can be handled. 

A Outline of the Soundness Proof 

A.l Scheme of the Proof 

Our soundness proof has a straightforward structure. First we build a model, using structural 
operational semantics (SOS) [13, 18, 6]. We then show how to interpret expressions and formulae 
of the logic in this model. Using the model, we define the set of execution sequences Tig used to 
define validity in Section 3.2. We prove a series of “sanity lemmas,” showing that the intuitive 
definitions presented earlier match the formal definitions. Finally, we check each of the axioms and 
proof rules against the model. 

The most subtle part of the construction is in building the model. Checking the axioms and 
proof rules is long but straightforward. In our model, we give a structural operational semantics 
for our programming language. States 7 include all of the information necessary to interpret Proof 
Outline Logic assertions. And, the operational semantics define the relation 7 <— ► 7', stating that a 
program in state 7 can perform a single atomic action, or can idle, and enter state 7'. 

Using <— ►, we construct a linear-time temporal-logic model of a program 5; that is, a set of 
infinite sequences T of states. We define a notion of “7 is a suitable initial state for 5”. We get an 
arbitrary consistent state 70 by running an arbitrary suitable initial state 7 for S arbitrarily long, 
7 *-►* 7 0 . is then the set of executions of S started in arbitrary consistent states 70. 

Having defined Wj, we have have enough information to use the definition of Section 3.2 that 
^ PO(S ) when Tig f= Ipo(S) => a Cpo(S)- This puts us in a position to check the soundness of the 
logic, which is tedious but not difficult. 

A. 2 Defining the transition relation 

Defining relation is nontrivial. The values of control predicates, especially at the beginning 
and end of concurrent segments, change in fairly complicated ways. Consider the program of 
Figure 11. When the cobegin labelled a finishes, after(c) or after(d) will hold as well as after(g) 
and after (/i); and at(j ), at(l), and at(m). A single atomic action — say, g finishing — may cause 
other actions at faraway points in the program to start. Or it may not. 
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a : cobegin 

b : if 

B\ — ► c: skip 

1 

B2 —> d: skip 

fi 

// 

e: skip 

/ : cobegin 

g : skip 

// 

h : skip 

coend 
coend 

i : cobegin 

j : skip 

// 

cobegin 

/ : skip 

// 

m : skip 
coend 
coend 


Figure 11 : Control flow example 

Any description of the state transition function will, at some level, involve an inductive analysis 
of the structure of the original program. We thus chose to define the operational semantics of 
processes directly, using SOS. In this style, the behavior of a composite program is defined in terms 
of the behavior of its subterms. Since the state 7 must contain enough information to interpret all 
assertions in Proof Outline Logic, it must include: 

• at(l) and after(l) for each label / 

• values of program variables 

• values of rigid variables 

• | at(l) and \after(l ) for each label / 

• T 

All save the first can be encoded directly as components of a tuple. For example, if 7 is a state, 
then 7-|at(-) is a function from program labels to times, and 7.tr(-) is a function from program 
variables to values. Following the usual SOS methodology, program counters in a state 7 are 
represented by the partial program 7 .5 that remains to be executed. We assume that programs are 
completely labelled; that is, each command (simple and composite) has a unique label, as in the 
example above. We also introduce a new command, done, indicating that a thread of computation 
has finished. 
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We now define the relation 7 «-+■ 7' by induction on 7 .S. By in large, if 7 ^ 7', then 7 and 7' 
are almost the same; e.g., most variables won’t change values. We therefore present the SOS rules 
by explaining the differences between 7 3Jid 7 ; -* For example, if 7 ’ S is the program / . skip, then 
the operational rule which applies to 7 is: 

If 

7.5 = l : skip 
7 '.S = l : done 

7 / .r > 7 .t 

7 ' is otherwise the same as 7 
Then 7 *-»• 7' 

The behavior of a composite process is determined inductively by the behavior of its subpro- 
cesses. For example, cobegin Si// • • • // S n coend can act if one of the Si s can act without exceeding 
the time bounds of the other 5j’s. This happens if there is a state 70 in which the program is simply 
the Si that performs the the transition. Thus, the rule for cobegin is roughly: 

If 

7.5 = cobegin Si// • • • // Si // •••//S n coend, 

7 .S' = cobegin Si// ■ • • // S'i// • • -//S n coend, 
where 37o,7o such that: 

7o.5 = Si 

70 is otherwise the same as 7 

7° 7o 

No other component of 7.5 is required to act before 'Jo-'T 

S'i = 7 4-5 

7' is otherwise the same as 70 
Then 7^7' 

Of course, the English antecedents are made formal. 

Idle actions are described by: 

If 

y.r > 7 -T 

7 .S is not required to act before 7 '.T 

7' is otherwise the same as 7 
Then 7 «— * ► 7' 

One important consequence of using a structural operational semantics is that 7 «-*■ 7' iff there 
is a proof of 7 7' from the operational rules. These proofs can be regarded as formal objects, 

and, in particular, we can do induction on the proof that 7 *— ► . Many of the basic lemmas used 

for soundness proceed by such inductions. 

This discussion omits subtleties that are essential to the proof. For the model construction, the 
actual proof rules assign responsibility for the transition, so that when we define Tig we can ensure 
that S takes all the transitions in Hg. Roughly, a subterm S' of the program 7-5 is responsible for 
the transition 7 7' if S' appears as 70 . S in the proof of 7 <-*• 7' or if the transition is idle. The 

determination of which processes are finished requires some care. For example, done is a finished 
atomic process, but there are also others, such as cobegin done/done coend. While the intuition 
is reasonably straightforward, the details are delicate. 

®In the full proof, we use a more standard SOS notation, which makes the structural induction clearer but requires 
extra notation. 
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A.3 Interpreting Expressions and Formulae 

The meanings of most expressions and formulae can be read directly from the state 7. For example, 
the value of the expression x + y in state 7 is the sum of 'y.o(x) and 'y-cr(y). However, the values of 
control predicates at(l ) and after(l) depend on the control state 7 .S of the program. In this section, 
we sketch the interpretations of these predicates for the case when / is the label of an atomic action. 

Let 7 be a state in an element of 7 fj. Interpreting after (l) where / is the label of an atomic 
action is straightforward; 7 .S includes a subterm of the form l : done if and only if the atomic 
action labelled / in 7.5 is finished. 

We define the set of active atomic actions of a program S inductively; e.g., if S is atomic, 
act(. 9 ) = { 5 }, and e.g. 

act(cobeginSi^ ■ • •/ ,r S n coend) = U t act (^«) 
if S\ is not finished, act (.Si .S?) = act (.Si ) 

if Si is finished, act(SiS2) = act^) 

Then 7 at(l) if / is the label of an atomic action in act(7.S). In the actual proof, we allow at(l) 
when l is the label of any program, not just the label of an atomic action. This complicates the 
definition of act somewhat and requires use of an extra set of markers in the operational semantics. 
However, it allows us to verify the Proof Outline Logic control predicate axioms without having 
built them directly into the definition of 7 ^ at(l). 

A. 4 Sanity Checking 

We demonstrate that the operational semantics and notion of interpreting processes are reasonable 
by proving a series of sanity lemmas. These are lemmas that are not necessarily used in the 
soundness proof proper but show that the formal definitions derived from the operational semantics 
agree with the less formal ones used in the body of this paper. The following sanity lemma, for 
example, shows that the intuitive definition of |at(0 as the last time that at(l) became true agrees 
with the formal definition of |af(/) as it appears in the operational semantics: 

Let 70 be a suitable initial state, and 70 ► 7i *-♦ ■ ■ •• Then, for any index i and 

label /, 7,-.fat(/) is: 

• -00 if (VO < j < i : 7 j at(l )) 

• jj.T if j is the largest 0 < j < i such that (7j-i at(l) and jj f= at(l)). 

• 7o.T, if neither of the preceding conditions obtains; that is, if 70 f= ot(l) but 
(A j : 7 j V 1 at ( l ) A 7 i+i 1 = «*( 0 )- 

That is, the time that the bookkeeping mechanism gives for |a<(/) is in fact the value of the clock 
on the most recent instant that at(l) became true. 

A. 5 Soundness 

Once the SOS rules have been constructed and their sanity checked, it is a routine matter to show 
soundness of all the Real-Time Proof Outline Logic axioms and proof rules. We define the model 
in the following way. We consider executions starting with S in an arbitrary state of control 
and memory. We allow other processes in this initial state as well. We thus consider executions 
that start with some program that includes S; we run this program for a time (which gives an 
arbitrary state, perhaps with 5 partially executed). However, in the sequences in TfJ, only S is 
allowed to take steps, so S must be responsible for each transition. 
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• 7 is an initial state for 5 iff 7.5 includes 5 as a subprogram, and 7.fa*(0 and after (l) are 

initialized properly. That is, 7 .\cp = 7 . T if 7-5 cp, and to —00 otherwise, for cp a control 
predicate. 

• W5 is the set of all sequences (7o>7i>-*.) such that 7 *— ♦* 70 for some initial state 7, and 
7 i > 7, +1 for every i, and 5 is responsible for each transition. 

Note that TfJ is suffix-closed; that is, if {70, 71, . . . , 7 «> 7«+i> • • •) € TfJ , then also (7«,7i+i, . . .) € TfJ . 

To prove the Control Predicate Axioms of Figure 1 sound, we characterize possible control 
states of a program and possible executions of a program. For example, omitting labels, done 5 is 
a possible subterm of a control state (as skip 5 can evolve into it); but 5 done is not possible (the 
first in a sequence of commands is executed before the second). 

Similarly, we say that program fragment S' is a descendant of S if (roughly) there are states 
7 <— ►* 7' such that 7.5 = 5 and 7 '.5 = 5'; it is a proper descendant if S ^ S'. We characterize the 
descendants of all terms. For example, let 5 be a command sequence l : ((m : 5 1 ) ( n : S^)), and S' 
be a descendant of S. Then there is at most one subterm of S' labelled /, and it must be: 

• / : ((m : 5()(n : S2)) where S[ is a descendant of 5i, or 

• / : (n : S' 2 ) where S ' 2 is a proper descendant of 52. 

Soundness of the Control Predicate Axioms follow easily from these characterizations. For 
example, for one direction of the axiom for sequencing, after(m) = at(n), we calculate that if 
7 f= after(m), then there must be a subterm m : done of 7.5. FYom the preceding characterization, 
this means that n : S2 must also be a subterm of 7 .5; and, by the definition of at(-), this implies 
that at(n ) holds as well. 

The other axioms and proof rules are proved similarly. For example, to show (22), we show by 
induction on the proof of 7 <—*■ 7' that 

(7 •— 7') => (7 -T < l'.T) (45) 

Suppose that 70 «-*• 71 «-*• • • • is a sequence of transitions from an initial state. By induction on i 
and the definition of initial state, we show that 7 ,-.|at(/) and 7j.f after(l) tire either — 00, or 7 j.T 
for some j < i. This and (45) suffices to show (22). 

Axioms and rules involving proof outlines require verifying statements of the form 7 i J |= /=>□/. 
From temporal logic, we know that, if /=► Q 7 is valid, so is 7 => □/. 7 is a predicate logic formula 
rather than a temporal one, hence it is true or false in a single state. It thus suffices to show that, 
for each 7 <— ►* 70 <— ► 71 where 7 is an initial state for 5, if 70 |= 7, then 71 f= 7. 

We use this method to verify each proof outline axiom and proof rule. All these verifications 
proceed by induction on the proof of the transition 70 '— *• 71. For example, to check skip Axiom (7), 
let 5 = / : skip. Ipo(S) = ( a< (0 ^ P) A (after(l) ^ P), where P is primitive. Suppose 70 (= Ipo{S)- 
It is easy to show that 7 \= P is independent of 7 .5 and 7.T if P is primitive. The proof comprises 
the following cases: 

1. The transition is idle, and 70 (= at(l). As 70 ^ Ipo(S)i we conclude 70 \= P . In this case, 
the only component of 71 that is different from 70 is 71 .T. Since the value of a primitive 
formula does not depend on 7.T, and since 70 f= P, we conclude 71 ^ P. This suffices to 
show 7! f= I P0 (sy 

2. The transition is idle, and 70 \= after(l). The proof proceeds as above. 
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3. The transition is not idle, in which case it proceeds by SOS rule for skip above. That is, 
7o .S = I : skip, 71 .S = l : done, and 70 and 71 are otherwise identical except possibly for 
7,.T. Note that 70 \= P, because 70 |= at (I) and 70 f= Ipo(S)- Primitive formulas do not 
depend on the changed components. Hence 71 (= P and, thus, 71 \= Ipo(S) as desired. 

4. 7 q |= -1 (at(l) A after(l)). In this case, S cannot be responsible for any non-idle transitions, 
and all transitions are thus idle. In particular, 71 (= -<(at(l)Aafter(l)), and hence 71 f= Tpo(S) 
vacuously. 

Each of the other axioms and rules of Real-Time Proof Outline Logic is handled in a similar 
manner, and thus we establish soundness. The subtle part of the proof is not checking these rules, 
so those details are omitted here. The subtle part is the definition of the real-time execution model 
that is explained above. 
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